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Odbiornik sygnatu danych programowany programem tadujacym i sposob 
aktualizacji oprogramowania w odbiorniku sygnatu danych za pomoca. 
. programu tadujacego 

fjf . 5 Przedmiotem wynalazku jest odbiornik sygnatu danych programowany 

programem tadujacym i sposob aktualizacji oprogramowania w odbiorniku 
sygnatu danych za pomoca. programu tadujacego, ktory moze bye 
wykorzystywany przyktadowo w odbiornikach sygnatu radiowego, telewizyjnego 
lub telefonii komorkowej, a zwtaszcza w dekoderach telewizji cyfrowej. 
10 Program tadujacy o nazwie angielskiej Loader obstuguje procedure, 

aktualizacji oprogramowania. Przetwarza odbierane przez urzadzenie pakiety 
danych i tworzy program, ktory jest zapisywany w pamieci FLASH urzadzenia. 

Stan techniki zawiera projekt nazwany EUROLOADER, w ktorym jest 
zawarta specyfika programu tadujacego dla dekoderow telewizji cyfrowej 
15 przyjete przez firmy zrzeszone w organizacji o angielskiej nazwie European 
Cable Communication Association, w skrocie ECCA. Projekt ten opisuje 
sposob dziatania programu tadujacego, ktory definiuje procedure aktualizacji 
oprogramowania w dekoderach. Wedtug specyfikacji dane dotycza.ee 
aktualizacji oprogramowania sa.cz?sto transmitowane aby uniknac opoznieh w 
20 aktualizacji. Aplikacje zostaty tu podzielone na program EUROLOADER oraz 
program operacyjny (aplikacje). Ponadto program EUROLOADER jest 
podzielony na dwie cz^sci: kod startera i loadera. Specyfikacja programu 
EUROLOADER wymaga od urzadzenia aby byto wyposazone w co najmniej 
cztery rodzaje pamieci, a mianowicie pamiec typu RAM, FLASH, ROM i NV- 
25 RAM. W pamieci typu RAM sa. przechowywane informacje tymczasowe, 
pamiec typu FLASH zawiera kod aplikacji, przy czym mozliwa jest aktualizacja 
danych zapisanych w pamieci typu FLASH. Z kolei w pamieci typu ROM sa_ 



przechowywane dane nie podlegajace aktualizacji, w tym czesckodu programu 
EUROLOADERA, ktorym jest kod startera. Pamiec typu NV-RAM jest 
przeznaczona gtownie na informacje o konfiguracji urzadzenia. 

Aktualny stan techniki znany z komputerow PC zawiera takze programy 
stuzace do kompresji plikow wykonywalnych z rozszerzeniem „.exe". Ich 
zadaniem jest kompresja programow w oparciu o znane rozwiazania 
samorozpakowujacych sie. archiwow, ktore po dekompresji plikow na dysk 
uruchamiajg.wtasciwy program. 

Istota. wynalazku jest to, ze w odbiorniku sygnatu danych 
programowanym programem tadujacym zawierajacym blok odbioru sygnatu, 
procesor, interfejsy, pamiec typu RAM, ROM, NV-RAM oraz pamiec nieulotna, 
procesor posiada wewnetrzny blok inicjujacy prace. programu ladujacego oraz 
blok obsiugi programu ladujacego, ktory na podstawie kodu zainicjowanego 
przez blok inicjujacy, steruje praca. programu tadujacego, ktory jest zapisany 
jako skompresowany w pam'^ci nieulotnej, a po zdekompresowaniu jest 
zapisany w czesci obszaru pamieci typu RAM zadeklarowanej jako pamiec 
typu ROM. 

Korzystnie obraz pamieci jest utworzony z czesci zawierajacej 
sekwencj? startowa. programu tadujacego, czesci zawierajacej tablice. skokow 
programu iadujacego oraz czesci zawierajacej obszar statycznych danych 
programu ladujaeego oraz kodu programu ladujacego.i jako. skompresowany 
jest zapisany w pamieci nieulotnej. 

Korzystnie tablica skokow programu tadujacego zawiera adresy funkcji 
wspolnych dla programu dekompresujacego oraz programu tadujacego, ktore 
to funkcje zdefiniowane sa_w programie dekompresujacym. 

Korzystnie zdekompresowany kod programu tadujacego jest 
umieszczony pod statym adresem w pamieci RAM. 

Korzystnie pamiec nieulotna jest pamiecig. typu FLASH. 

Istota. wynalazku jest rowniez to, ze w sposobie aktualizacji 
oprogramowania w odbiorniku danych za pomoca. programu tadujacego 
przechowywanego w pamieci nieulotnej zawierajacym blok odbioru sygnatu, 
procesor, interfejsy, pami?c typu RAM, ROM, NV-RAM oraz pamiec nieulotna. 
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60 oprogramowanie aktualizujace zapisuje sie jako skompresowane w pamieci 
nieulotnej, a podczas uruchomienia procedury startowej kopiuje sie je pod staty 
adres w czesci obszaru pamieci typu RAM, ktora przed procesem taczenia 
zostata zadeklarowana jako pamiec typu ROM. 

Korzystnie procedura startowa programu tadujacego wykonywana jest 
65 przy wtaczeniu odbiornika do zasilania. 

Korzystnie procedura startowa programu tadujacego uruchamiana jest 
na zadanie uzytkownika. 
'"'W** Korzystnie procedura startowa programu tadujacego uruchamiana jest 

przez zewnetrzny sygnat, przesytany do odbiornika. 
@" 70 Korzystnie obraz pamieci tworzy sie z czesci zawierajacej sekwencje 

startowa. programu tadujacego, czesci zawierajacej tablice. skokow programu 
tadujacego oraz czesci zawierajacej obszar statycznych danych programu 
tadujacego oraz kodu programu tadujacego a nastepnie obraz pamieci 
kompresuje si§. 

75 Korzystnie tworzy sie tablia? zawierajaca adresy funkcji wspolnych dla 

programu dekompresujacego oraz programu tadujacego, ktore to funkcje 
zdefiniowane sa_w programie dekompresujacym. 

Korzystnie program tadujacy rozpoczyna procedure, aktualizacji aplikacji 
sprawdzajac czy aktualnie nadawany w strumieniu program jest przeznaczony 
80 dla odbiornika, z ktorego zostat uruchomiony program taduja_cy, co stanowi 
warunek aktualizacji aplikacji. 

Przedmiot wynalazku jest uwidoczniony w przyktadzie wykonania na 
rysunku, na ktorym fig. 1A przedstawia dekoder telewizji cyfrowej w 
uproszczonej wersji, fig. 1B przedstawia telefon komorkowy w uproszczonej 
85 wersji, fig. 2 przedstawia organizacje pamieci typu FLASH, fig. 3A przedstawia 
algorytm uruchamiania nieskompresowanego programu tadujacego, fig. 3B 
przedstawia algorytm uruchamiania skompresowanego programu tadujacego, 
fig. 4 przedstawia. organizacje pamieci typu RAM dla skompresowanego 
programu tadujacego, fig. 5 przedstawia procedure tworzenia 
90 skompresowanego obrazu pamieci, fig. 6 przedstawia procedure dekompresji 
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(rozpakowania) programu tadujacego, fig. 7 przedstawia tablice skokow 
programu tadujacego. 

Przedstawiony sposob moze bye zastosowany w roznego rodzaju 
odbiornikach sygnalu, z ktorych dekoder telewizji cyfrowej zostat podany 
95 jedynie jako przyktad. Do odbiornikow takich mozna rowniez zaliczyc telefony 
komorkowe, palmtopy, odbiorniki radiowe oraz wszelkie inne urzadzenia, w 
ktorych mozliwa jest aktualizacja oprogramowania poprzez odbierany przez nie 
sygnat zewn^trzny. 

Fig. 1 przedstawia w uproszczonej wersji odbiornik sygnalu 

100 telewizyjnego, ktorym jest dekoder telewizji cyfrowej 101.. Gtownym elementem 
dekodera telewizji cyfrowej 101 jest procesor 120, ktory zarzadza praca. 
odbiornika. Procesor zawiera wewnetrzny blok inicjujacy 121, ktory inicjuje 
prace programu tadujacego oraz blok obstugi programu tadujacego 122 . ktory 
na podstawie kodu zainicjowanego przez blok inicjujacy 121 . steruje praca. 

105 programu tadujacego. Do procesora podawany jest sygnat z bloku odbioru 
sygnatu MPEG 110 . Dodatkowo procesor 120 ma mozliwosc dwukierunkowej 
wymiany danych poprzez interfejsy zewn^trzne 140 . Mozliwa jest takze 
wymiana danych z pilotem zdalnego sterowania 131 oraz przekazywanie 
sygnatu audio/wideo 130 do odbiornika, na przyktad telewizora. Dekoder 

110 telewizji cyfrowej zawiera takze kilka rodzajow pamieci, ktore sa. 
• dwukierunkowo potaczone z procesorem. Sa. to pamieci typu FLASH 150 i 
RAM 160. W pamieciach tych przechowywane sa. programy sterujace praca. 
dekodera telewizji cyfrowej, wtaczajac w to skompresowany program 
tadujacego, w ktorym zapisany jest sposob kontroli pamieci nieulotnej, 

115 przyktadowo typu FLASH 150 oraz pamieci typu RAM 160 dekodera. Program 
tadujacy jest programem, ktory odbiera kod dekodera z zewnetrznych zrodet i 
wymienia go w dekoderze telewizji cyfrowej, zapisujac go do pamieci typu 
FLASH 150 dekodera telewizji cyfrowej. Program tadujacy nie zajmuje s\q 
odtwarzaniem sygnatow audio lub wideo ale jest w stanie komunikowac si§ z 

120 uzytkownikiem urzadzenia wyswietlajac informacje na ekranie w celu 
pokazania stanu aktualnie wykonywanego uaktualnienia kodu oprogramowania 
dekodera. 
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Innym odbiornikiem, dla ktorego mozna zastosowac rozwiazanie wedtug 
wynalazku, jest telefon komorkowy 211- Telefon taki zostat przedstawiony na 

125 fig. 1 B. Wewnetrzne elementy 221 > 222 procesora 220, petnia^te same funkcje 
co w przypadku dekodera telewizji z fig. 1A, podobnie jak pamieci 250 i 260. 
Zmieniaja. sie natomiast elementy odbiornika petniace funkcje komunikacji ze 
zrodtami danych oraz komunikacji z uzytkownikiem. Do pierwszej grupy 
uktadow naleza. blok nadawczo/odbiorczy sygnatu GSM 210 oraz blok 

1 30 interfejsow zewnetrznych 240 na przyktad IrDA. Druga grupa uktadow obejmuje 
b | 0 k sterowania wyswietlaczem telefonu 230 oraz blok sterowania klawiatura. 
231 , Podobne, oczywiste dla specjalisty roznice, mozna znalezc w innych 
£p urzadzeniach w ktorych zastosowany bytby sposob wedtug wynalazku. 

Kod, ktory jest przechowywany w dekoderze telewizji cyfrowej, jest 

135 podzielony na dwie czesci: kod dekodera oraz program tadujacy. Kod 
dekodera, nazywany takze kodem wysokiego poziomu lub aplikacjaj jest 
odpowiedzialny za odbior, dekodowanie oraz wyswietlanie sygnatow audio, 
wideo oraz innych komponentow takich jak teletekst czy napisy w roznych 
wersjach j^zykowych. 

140 Program tadujacy moze bye uruchamiany za kazdym razem, gdy 

podlacza sie dekoder telewizji cyfrowej do zrodta zasilania. Po uruchomieniu 
program iadujacy sprawdza mozliwe zrodla aplikacji. Jesli dostepna jest 
mozliwosc -aktualizacji. aplikacji przez zewn^trzne interfejsy. dekodera 140,. 
%i program Iadujacy sprawdza mozliwosc aktualizacji i w razie mozliwosci 

4^ 145 rozpoczyna wymiane aplikacji. Jesli natomiast dostepna jest mozliwosc 
wymiany aplikacji z uzyciem sygnalow nadawanych w sygnale telewizji 
satelitarnej, kablowej lub naziemnej odbieranym przez blok odbioru sygnatu 
110 , program Iadujacy ustawia sie na odpowiedni strumien danych, uzywajac 
parametrow zapisanych w pamieci NV-RAM. Program Iadujacy rozpoczyna 

150 procedure aktualizacji aplikacji sprawdzajac czy aktualnie nadawany w 
strumieniu program jest przeznaczony dla dekodera telewizji cyfrowej, z 
ktorego zostal uruchomiony program tadujacy. Jesli tak, procedura aktualizacji 
jest akceptowana. 
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Program Jaduj^cy moze bye uruchamiany rowniez na zqdanie 
155 uzytkownika lub aktywowany okreslonym sygnatem ze strony nadawcy. 
Nadawca moze przestec sygnal informuj^cy o dost^pnej nowej wersji 
oprogramowania, a uzytkownik po odebraniu tej informacji moze wydac 
z^danie uruchomienia programu tedujatcego lub tez program taduj^cy moze bye 
uruchomiony automatycznie. W sygnale tym mog^. bye przestane dodatkowe 
160 informacje 0kreslaj3.ee zrodto i typ przesyJanych danych. Zarowno kod 
aplikacji jak i kod programu tadujcipego przechowywane w pami^ci typu 
^Pk' . FLASH 150 dost^pnej w dekoderze telewizji cyfrowej. Fig. 2 przedstawia 

organizacj? pami^ci typu FLASH dekodera przedstawionego na fig. 1. Pami^c 
typu FLASH jest podzielona na cztery cz^sci. Pierwsza cz<?sc 201 zawiera 
1 65 oprogramowanie dekodera, druga cz^sc 202 to wolny obszar pami^ci, jesli taki 
jest dost^pny. Nast^pna cz^sc 203 zawiera opcjonalne dane aplikacji, ostatnia 
cz^sc to kod programu tedujqeego 204. Przewaznie obszar pami^ci dost^pny 
dla kodu programu taduj^cego to 128 kilobajtow. Na pocz^tku startu programu 
tadujetcego, caly jego kod jest kopiowany do pami^ci typu RAM 160 dost^pnej 
1 70 w dekoderze telewizji cyfrowej. 

Fig. 3A przedstawia algorytm uruchamiania programu tadujqeego. W 
kroku 301 uruchamiany jest program startuj^cy, ktory rozpoczyna swojci prac§ 
bezposrednio po wt^czeniu zasilania dekodera telewizji cyfrowej lub po 
ustawieniu wartosci pocz^tkowych (restarcie) systemu. Procedura opcjonalnie. 
175 inicjuje pami^c typu FLASH zaleznie od konfiguracji oraz sprawdza aktualny 
stan dekodera telewizji cyfrowej w celu ustalenia przyktadowo czy uruchomic 
program ladujcjcy czy program aplikacji. W kroku 302 wykonywana jest cz^sc 
inicjuj^ca, ktora zalezy od sprz^towej konfiguracji dekodera, przykladowo kod 
programu jest kopiowany z pami^ci typu FLASH do pami^ci typu RAM. W 
180 kroku 303 jest wywotywana funkeja main(), ktora uruchamia program ladujsjcy, 
a w kroku 304 program laduj^cy jest realizowany. 

Fig. 3B przedstawia algorytm uruchamiania skompresowanego 
programu tadujgeego wedtug wynalazku, maj^cego zastosowanie zwlaszcza w 
rozbudowanych konfiguracjach. W niektorych konfiguracjach kod programu 
185 tadujqeego jest na tyle rozbudowany, ze nie mozna go umiescic w dost^pnych 
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128 kilobajtach w pamieci typu FLASH 150. Aby zmniejszyc objetosc programu 
tadujacego stosuje sie kompresje jego kodu. Wprowadzenie kompresji kodu 
programu tadujacego wptywa na zwiekszenie puli dostepnej pamieci dla 
przyktadowo rozbudowanych sterownikow do poszczegolnych czesci dekodera 
190 telewizji cyfrowej przykladowo modulatora czy tunera. W tym przypadku kod 
programu tadujacego sktada sie z: rzeczywistej aplikacji programu tadujacego 
oraz modulu dekompresujacego (przywracajacego pierwotna. strukture kodu 
programu ladujacego), ktory rozpakowuje wtasciwy kod programu ladujacego 
do pamieci typu RAM 160 dostepnej w dekoderze telewizji cyfrowej. Procedura 
195 uruchomienia tak skompresowanego programu jest podzielona na dwie czesci. 
V?) Pierwsza czesc, skladajaca sie z krokow 305, 306, 307, 308, 309, 310 jest 

obslugiwana przez program dekompresujacy, a druga czesc, skladajaca sie z 
kroku 3H jest obslugiwana przez program tadujacy. W kroku 305 uruchamiany 
jest program startowy po wtaczeniu zasilania dekodera telewizji cyfrowej lub po 
200 ustawieniu wartosci poczatkowych (restarcie) systemu. W kroku 306 nastepuje 
kopiowanie kodu z pamieci typu FLASH do pamieci typu RAM. W kroku 307 
nastepuje dekompresja (rozpakowanie, przywrocenie pierwotnej postaci kodu) 
programu do pamieci typu RAM dekodera telewizji cyfrowej. W kroku 308 
nastepuje weryfikacja zdekompresowanego programu, czyli kodu w pierwotnej 
205 postaci. Nastepnie w kroku 309 inicjuje sie tablice. skokow, ktora zostala 
przedstawiona na fig. 7. W kroku 310 jest wykonywana funkcja main(), ktora 
% uruchamia program tadujacy. W kroku 311 nastepuje uruchomienie programu 

ladujacego. 

Nieskompresowane programy tadujace mogst zostac umieszczone w 
210 dowolnym obszarze dostepnej pamieci. W przypadku skompresowanego 
programu ladujacego korzysta sie ze statych adresow pamieci, aby poprawne 
byly odwotania do miejsc zawierajacych zmienne, state lub wskazniki do 
funkcji. Dlatego, dodatkowo zaktada sie, ze zdekompresowany kod programu 
tadujacego jest umieszczony pod statym adresem w pamieci typu RAM. Aby 
215 uchronic sie przed dodaniem przez program taczacy, po angielsku linker, 
procedur, ktore standardowo sa_ dota.czane, gdy kod jest umieszczony w 
pamieci typu RAM, niezbedne jest podanie programowi laczacemu, ze ten 
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obszar, przeznaczony na program tadujacy, to pamiec typu ROM. Podczas 
taczenia procedur przez program taczacy nastepuje zebranie wszystkich 

220 modutow danego programu, uzupetnienie informacji o odwotaniach pomiedzy 
poszczegolnymi modutami, przypisanie ostatecznych adresow dla funkcji i dla 
danych, dla ktorych nie zostato to zrobione na etapie kompilacji programu oraz 
wygenerowanie programu wynikowego. 

Obsluga skompresowanego programu tadujacego wymaga specjalnego 

225 podejscia do operacji umieszczania programow i ich danych w pamieci typu 
FLASH. Przyjmuje sie, ze adresy pamieci typu RAM zaczynaja. sie od adresu 
OxCOOOOOOO i rozmiar pamieci wynosi osiem megabajtow a pamieci typu 
FLASH cztery megabajty. Zwiekszenie ilosci dostepnej pamieci typu RAM 
powoduje wzrost ilosci dostepnego miejsca dla obszaru ogolnego 

230 przeznaczenia. Adresy pozostatych obszarow sa, state. 

Fig. 4 przedstawia szczegotowa. organizacje (podziat) pamieci typu 
RAM. Blok 401 reprezentuje obszar zarezerwowany przez program tadujacy, 
czyli obszar pamieci zarezerwowany dla sterownikow OSGL (skrot od 
angielskich stow On Screen Graphic for Loader), odpowiedzialnych za 

235 wyswietlanie elementow na ekranie odbiornika) oraz DMUX (skrot od 
angielskich stow DeMUItipleXer submodule), kontrolujacy filtrowanie danych 
przychodzacych do dekodera telewizji cyfrowej, ktore sq. przeznaczone dla 
. programu tadujacego. 



Adres: 


OxCOOOOOOO 


Rozmiar. 


256 kB 



240 

Blok 402 reprezentuje sekwencje. startowa. programu tadujacego, to jest 
obszar pamieci, ktory zawiera blok kodu startowego. Adres pierwszego bajtu z 
obszaru 402 (OxC0040000) jest punktem startowym dla programu tadujacego. 

245 



Adres: 


OxC0040000 


Rozmiar: 


64 kB 
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Blok 403 reprezentuje obszar pamieci zarezerwowany przez tablice. 
skokow programu ladujacego do funkcji wspolnych dla programu tedujacego i 
250 modulu dekompresujacego (przywracajacego pierwotna. postac kodu). 



Adres: 


0xC0040040 


Rozmiar: 


960 B 



Blok 404 reprezentuje obszar pami^ci zaj^ty przez kod programu 
255 taduj^cego po dekompresji oraz przez statyczne dane programu tadujqcego, 
przyktadowo stale lub statyczne zmienne. 



Adres: 


0xC0040400 


Rozmiar: 


255 kB 



260 Blok 405 reprezentuje zakres pamieci zaj^ty przez kod programu 

dekompresujacego oraz przez statyczne dane programu dekompresujacego, 
. przykladowo stale lub statyczne zmienne. 



Adres: 


0xC0080000 


Rozmiar: 


20 kB 



265 

Blok 406 reprezentuje obszar ogolnego przeznaczenia zarezerwowany 
w pami§ci. Obszar 406 reprezentuje zakres adresow przeznaczony zarowno na 
dane programu dekompresujacego, w tym skompresowany kod programu 
tadujgcego oraz kod modulu programu ladujgcego. 
270 Wykorzystanie skompresowanego programu laduj^cego w dekoderach 

telewizji cyfrowej wymaga wykonania procedury tworzenia obrazu pami^ci 
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RAM. Aby wykonac te procedure po kompilacji i taczeniu tworzy sie dwa pliki 
zawieraja.ee obraz pamieci. W niektorych systemach sa. one oznaczone 
rozszerzeniem „.hex". Pierwszy zawiera sekwencje startowa. programu 
275 tadujacego umieszczona. w bloku 402, drugi to segment pamieci zawierajacy 
statyczne dane i kod programu tadujacego umieszczone w bloku 404. Bloki 402 
i 404 sa. uzywane do stworzenia obrazu pamif ci typu RAM. 

Fig. 5 przedstawia procedure tworzaca. skompresowany obraz pamieci. 
$ Po starcie, w kroku 501 sa. odczytywane pliki z obrazem pamieci. W kroku 502 

280 sa. sprawdzane wejsciowe pliki z obrazem pamieci, a mianowicie czy dane 
statyczne i kod programu Iadujacego sa. umieszczone we wtasciwym przedziale 
adresow. Jezeli pliki nie sa. poprawne, w kroku 506 jest wyswietlana informacja 
o btedzie i nastepuje zakonczenie procedury. W przypadku, gdy pliki sa. 
poprawne, w kroku 503 tworzony jest obraz pamieci typu RAM. Obraz taki 
285 stanowi tablice bajtow ztozona. w kolejnosci z obszarow 402, 403, 404 pamieci. 
Na etapie tworzenia obrazu pamieci typu RAM, obszar 403 jest wypelniony 
zerami. W kroku 504 obraz pamieci jest kompresowany, a w kroku 505 jest 
tworzony plik naglowkowy programu tadujacego zawierajacy skompresowany 
obraz pamieci typu RAM oraz informacje potrzebne do poprawnej dekompresji 
290 oraz umieszczenia kodu programu tadujacego w pamieci typu RAM. 

Plik nagtowkowy programu tadujacego zawiera nastepuja.ee opeje dla 
. modutu dekompresujacegoL ... 

('] : loader_area_start_addr - adres do miejsca w pamieci, gdzie rozpoczyna 

sie sekwencja startowa programu tadujacego - blok 401; 

™' 295 loader_area_size - zmienna okreslajaca wielkosc bloku dostepnego dla 

programu tadujacego; 

loader_code_size - zmienna okreslajaca rozmiar kodu po wykonaniu 

operacji kompresji; 

compressed_loader_crc - suma kontrolna skompresowanego kodu 

300 programu tadujacego; 

— loader_compression - wybrany typ kompresji; 

original_code_addr - adres kodu programu tadujacego po dekompresji - 

blok 404 
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original_code_size - rozmiar kodu programu tadujacego przed 

305 kompresjaj 

original_code_crc - suma kontrolna kodu programu ladujacego przed 

kompresja,. 

Fig. 6 przedstawia procedure dziatania programu dekompresujacego 
program ladujacy. Plik nagtowkowy programu tadujacego jest wykorzystywany 
310 przez modut programu dekompresujacego, ktorego jest czescia.. W kroku 601 
nastepuje dekompresja kodu programu ladujacego do pamieci typu RAM pod 
*£f- adres 0x0040400. W kroku 602 sprawdza sie. czy wystapit Wad podczas 

dekompresji kodu. W przypadku wystapienia Wedu, nastepuje przejscie do 
t; • kroku 607. Jezeli nie ma Wedu, to w kroku 603 jest obliczana suma kontrolna 

315 CRC zdekompresowanego programu Jadujacego i nastepuje przejscie do kroku 

604 . w ktorym sprawdzane jest, czy suma kontrolna CRC jest poprawna. Gdy 
suma kontrolna nie jest poprawna, ma miejsce przejscie do kroku 607. W 
przypadku, gdy suma jest poprawna, nastepuje najpierw przejscie do kroku 

605 . gdzie program dekompresujacy inicjalizuje tablice. skokow programu 
320 ladujacego, ktora jest przedstawiona na fig. 7, a nastepnie przejscie do kroku 

606 . Zainicjowanie tablicy skokow jest czescia. procesu dekompresujacego i 
wykonywane jest poprzez wypelnianie jej odpowiednimi adresami. W kroku 607 
procedura sprawdza, czy kod aplikacji jest poprawny a nastepnie w kroku 608 
sprawdza czy wystapit Wad. Jezeli nie wystapH btad, to w kroku 609 dla 

<f ? 325 dekodera telewizji cyfrowej ustawiane sa_ parametry poczatkowe i procedura 
konczy dziatanie uruchamiajac aplikacj§. Jezeli wystapit btad, nastepuje 
przejscie do kroku 610 . gdzie procedura ustawia parametry poczatkowe dla 
dekodera. Sumy kontrolne liczone sa_ dla obrazow pamieci przed i po 
kompresji, tak aby program dekompresujacy mogt sprawdzic poprawnosc kodu 
330 programu tadujacego przed skompresowaniem i po dekompresji. 

Fig. 7 przedstawia tablicy skokow programu tadujacego. Tablica jest 
zbiorem adresow, z ktorych kazdy zajmuje obszar czterech bajtow. Tablic? 
rozpoczyna adres bazowy 701 globalnych zmiennych statycznych. Nastepnymi 
adresami sa, adres 702 funkcji inicjujacej tablicy wykorzystywana. do liczenia 
335 sum kontrolnych CRC, adres 703 funkcji liczacej sum? kontrolna, CRC 16, 
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adres 704 funkcji Hcz^cej sum? kontroln^. CRC 32, adres 705 funkcji licz^cej 
sum? kontroln^ CRC MPEG32, adres 706 funkcji A do dekompresji programu 
taduj^cego oraz adres 707 funkcji B do dekompresji danych aktualizacyjnych. 
Istniej^ dwie funkcje dekompresuj^ce, gdyz program laduj^cy moze bye 
340 skompresowany inn^ metodq. kompresji, niz dane aktualizacyjne, ktore s^ 
odbierane. 

Zastosowanie skompresowanego programu tadujqeego daje mozliwosc 
korzystania z wi?kszej ilosci sterownikow oraz zmniejsza wymagan^. ilosc 
pami?ci nieulotnej, na przyktad typu FLASH, ktore w przeliczeniu na jednostk? 

345 pami?ci, s^ drozsze od pami?ci typu RAM. W odroznieniu od rozwi^zan 
znanych z komputerow PC zastosowanie kompresji w urz^dzeniach, ktore nie 
posiadajX dysku twardego jest znacznie trudniejsze ze wzgl?du na wymog 
stworzenia odpowiedniej struktury pami?ci typu RAM i wykorzystaniu tej 
struktury. Ponadto w rozwi^zaniu korzysta si? z obrazow pami?ci a nie z plikow 

350 wykonywalnych tak jak ma to miejsce w aktualnym stanie techniki. 
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Zastrzezenia patentowe 

1. Odbiornik sygnatu danych programowany programem tadujacym 
zawierajacy blok odbioru sygnatu, procesor, interfejsy, pamiec typu RAM, ROM, 

5 NV-RAM oraz pamiec nieulotna^ znamienny tym, ze procesor zawiera 
wewnetrzny blok ( 121 . 221 ) inicjujacy prace programu tadujacego oraz blok 
obstugi programu tadujacego (122, 222), ktory na podstawie kodu 
zainicjowanego przez blok inicjujacy (121, 221), steruje pracq. programu 
tadujacego, ktory jest zapisany jako skompresowany w pamieci nieulotnej (150, 
10 250 ). a po zdekompresowaniu jest zapisany w czesci obszaru pamieci typu 
RAM ( 160 . 260 ) zadeklarowanej jako pamiec typu ROM. 

2. Odbiornik sygnatu danych wedtug zastrz. 1 znamienny tym, ze obraz 
pamieci jest utworzony z czesci zawierajacej sekwencje startowa. programu 

15 tadujacego, czesci zawierajacej tablice- skokow programu . tadujacego oraz 
czesci zawierajacej obszar statycznych danych programu tadujacego oraz kodu 
programu ladujacego i jako skompresowany jest zapisany w pamieci nieulotnej 
( 150 . 250 ). 

20 3. Odbiornik sygnatu danych wedtug zastrz. 1 znamienny tym, ze tablica 
skokow programu tadujacego zawiera adresy funkcji wspolnych dla programu 
dekompresujacego oraz programu tadujacego, ktore to funkcje zdefiniowane sa_ 
w programie dekompresujacym. 

25 4. Odbiornik sygnatu danych wedtug zastrz. 1 znamienny tym, ze 
zdekompresowany kod programu tadujacego jest umieszczony pod statym 
adresem w pamieci RAM. 
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5. Odbiornik sygnalu danych wedtug zastrz. 1 znamienny tym, ze pamiec 
nieulotna (150, 250 ) jest pamieciajypu FLASH. 

30 

6. Sposob aktualizacji oprogramowania w odbiorniku danych za pomoca. 
programu ladujacego przechowywanego w pamieci nieulotnej zawierajacym 
blok odbioru sygnalu, procesor, interfejsy, pamiec typu RAM, ROM, NV-RAM 
oraz pamiec nieulotna. znamienny tym, ze oprogramowanie aktualizujace 

35 zapisuje si? jako skompresowane w pamieci nieulotnej (150, 250), a podczas 
uruchomienia procedury startowej kopiuje si? je pod staty adres w czesci 
obszaru pamieci typu RAM ( 160 . 260 ). ktora przed procesem laczenia zostata 
zadeklarowana jako pamiec typu ROM. 

40 7. Sposob aktualizacji oprogramowania w odbiorniku danych wedtug zastrz. 
6 znamienny tym, ze procedura startowa programu tadujacego wykonywana 
jest przy wtaczeniu odbiornika do zasilania. 

8. Sposob aktualizacji oprogramowania w odbiorniku danych wedtug zastrz. 
45 6 znamienny tym, ze procedura startowa programu tadujacego uruchamiana 

jest na zadanie uzytkownika. 

9. . Sposob aktualizacji oprogramowania w odbiorniku danych wedtug zastrz. 
6 znamienny tym, ze procedura startowa programu tadujacego uruchamiana 

50 jest przez zewn?trzny sygnat, przesytany do odbiornika. 

1 0. Sposob aktualizacji oprogramowania w odbiorniku danych wedtug zastrz. 
6 znamienny tym, ze obraz pamieci tworzy sie z czesci zawierajacej sekwencje. 
startowa. programu ladujacego, czesci zawierajacej tablice skokow programu 

55 tadujacego oraz czesci zawierajacej obszar statycznych danych programu 
tadujacego oraz kodu programu ladujacego a nastepnie obraz pamieci 
kompresuje si?. 
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1 1 . Spos6b aktualizacji oprogramowania w odbiorniku danych wedtug zastrz. 
60 6 znamienny tym, ze tworzy sie. tablice zawierajaca adresy funkcji wspolnych 

dla programu dekompresujacego oraz programu tadujacego, ktore to funkcje 
zdefiniowane sa_w programie dekompresujacym. 

1 2. Sposob aktualizacji oprogramowania w odbiorniku danych wedlug zastrz. 
6 znamienny tym, ze program tadujacy rozpoczyna procedure aktualizacji 
aplikacji sprawdzajac czy aktualnie nadawany w strumieniu program jest 
przeznaczony dla odbiornika, z ktorego zostaJ uruchomiony program tadujacy, 
co stanowi warunek aktualizacji aplikacji. 
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Data signal receiver programmed by the loader and a method of updating 
software in a data signal receiver by means of the loader 

The object of the invention is a data signal receiver programmed by the loader 
and a method of updating software in a data signal receiver by means of the loader, 
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which can be used for example in radio, television or mobile telephony signal receivers, 
and especially in decoders of digital television. 

The loading program called the loader services the procedure of updating 
software. It processes data packets received by the device and creates a program, 
which is stored in the FLASH memory of the device. 

The state of technique includes a project called EUROLOADER, in which there is 
a specificity of the loader included for decoders of digital television, accepted by 
companies associated in the organization called the European Cable Communication 
Association, abbreviated as ECCA. This project describes a method of operation of the 
loader, which defines the procedure of updating software in decoders. Data related to 
software updates, according to the specification, are frequently transmitted in order to 
avoid delays in updating. The applications were divided here into the EUROLOADER 
program and operating program (application). Moreover the EUROLOADER program is 
divided into two parts: the starter's and loader's code. The specification of the 
EUROLOADER program requires from the device to be equipped with at least four types 
of memory, that is to say memory of RAM, FLASH, ROM and NV-RAM type. The RAM 
type memory stores temporary information, the FLASH type memory contains the 
application code, while updating data recorded in the FLASH type memory is possible. 
In turn, data which are not subject to updating are stored in the ROM type memory, 



including the part of the code of the EUROLOADER program, it is the starter code. The 
storage of NV-RAM type is mainly dedicated to information about the configuration of the 
device. 

The prior art, known from PC computers includes also programs, used, for 
compression of executable files with '.exe' extension. Their task is to compress 
programs based on the known solutions of self-extracting archives, which, after a 
decompression of files into a disk, start the appropriate program. 

The essence of the invention is that in the data signal receiver, which is 
programmed by the loader, including a signal receiving block, the processor, interfaces, 
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RAM type storage, ROM, NV-RAM and non-volatile memory, the processor has internal 
block initiating the operation of the loader and a block for servicing the loader. The block 
for servicing the loader, based on the code, initiated by the initiation block, controls 
operation of the loader. It is stored in a compressed form in the non-volatile memory, 
and after being decompressed it is stored in the RAM type memory area, which is 
declared as a ROM type memory. 

Favorably, the memory image is created from the part, including the table of 
jumps of the loader and a part, including the area of static data of the loader and the 
code of loader. The compressed memory image is recorded in the non-volatile memory. 

Favorably, the jumps table of the loader includes addresses of common functions 
for the decompressing program and the loader, the functions of which are defined in the 
decompressing program. 

Favorably, the decompressed code of the loader is placed under a fixed address 
in the RAM memory. 

Favorably, the non-volatile memory is a FLASH type memory. 

The essence of the invention is in the method of updating the software in the data 
receiver by means of the loader stored in the non-volatile memory, the receiver also 
including signal reception block, the processor, interfaces, RAM, ROM, NV-RAM type 
memories and non-volatile memory 



the updating software is stored in a compressed form in the non-volatile memory, and 
during the activation of the start procedure it is copied under a fixed address in a part of 
RAM type memory, which before the process of linking was declared as ROM type 
memory. 

Favorably, the start procedure of the loader is executed at plugging the receiver 
to the power supply. 

Favorably, the start procedure of the loader is started on the request of the user. 
Favorably the start procedure of the loader is started by an external signal, Send 
to the receiver. 
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Favorably the memory image is being created from the part, including the start 
sequence of the loader, a part containing the jumps table of the loader and a part 
including the static data area of the loader and the code of the loader, and next the 
memory image is compressed. 

Favorably a table is created, containing the addresses of common functions for 
the decompressing program and the loader. These functions are defined in the 
decompressing program. 

Favorably, the loader starts the procedure of updating the application by checking 
if the program, which is currently broadcasted in the stream is dedicated to the receiver, 
from which the loader was started. It is a condition of updating the application. 

The object of invention is illustrated in the example of embodiment in the drawing, 
in which fig. 1A shows a digital TV decoder in a simplified form, fig. 1B shows a mobile 
phone in a simplified version, fig. 2 shows organization of FLASH type memory. Fig. 3A 
shows the algorithm of starting the uncompressed loader, fig. 3B shows the algorithm of 
starting the compressed loader, and fig. 4 shows organization of RAM type storage for a 
compressed loader. Fig. 5 shows the procedure of creating the compressed memory 
image; fig. 6 shows the procedure of decompressing 



(unpacking) the loader, fig. 7 shows the jumps table of the loader. 

The presented method can be applied in various types of signal receivers, of which the 
digital TV decoder was given only as an example. Such receivers can also include 
mobile phones, palmtops, radio receivers and all other devices, where software updating 
is possible through the external signal received by them. 

Fig. 1 shows a television signal receiver in a simplified form, which is digital TV 
receiver 101 . The main element of the digital television receiver 101 is a processor 120, 
which manages the work of the receiver. The processor includes an internal initiating 
block 121 . which initiates the operation of the loader and the block of servicing the 
loader 122, which on the basis of the code, initiated by the initiating block 121, controls 
the work of the loader. The processor receives a signal from the MPEG signal reception 
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block 110 . Additionally the processor 120 has a possibility of bidirectional exchange of 
data with the remote control unit 131 and transmitting audio/video signal 130 to the 
receiver, for example a television set. The decoder of digital television includes also a 
few types of storage, which are biddirectionally linked with the processor. These are 
FLASH type 150 and RAM type memories 160. These memories store programs 
controlling the work of the digital TV decoder, including the compressed loader, in which 
the method of controlling non-volatile memory is recorded, for example FLASH type 150 
and RAM 160 of the decoder. The loader is a program, which receives the code of the 
decoder from external sources and exchanges it in the decoder of digital television, 
writing it to the FLASH 150 type memory of the digital TV decoder. The loader does not 
deal with playback of audio or video signals but it is able to communicate with the user 
of the device displaying information on the screen in order to show the status of the 
currently performed update of the decoder's software code. 



Another receiver, to which the solution, according to the invention, can be 
applied, is a mobile phone 211 . Such telephone is presented in fig. 1B. Internal 
elements 221 and 222 of the processor 220 , serve the same functions as in case of the 
television decoder from fig. 1 A, alike the memories 250 and 260 . However the elements 
of the receiver change. They serve the function of communication with data sources and 
communication with the user. The first group of systems includes a signal 
transmission/reception block GSM 210 and a block of external interfaces 240 for 
example IrDA. The second group of systems includes the telephone's display control 
block 230 and keypad control block 231 . Similar differences, obvious for a specialist, can 
be found in other devices, in which the method of this invention would be applied. 

The code, which is stored in a decoder of digital television, is divided into two 
parts: the decoder's code and the loader. The decoder's code, called also a high level 
code or an application, is responsible for reception, decoding and display of audio, video 
signals and other components such as teletext or subtitles in different language 
versions. 
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The loader can be started each time, when a digital TV decoder is connected to 
the power supply. After the start, the loader checks the possible sources of applications. 
If there is a possibility of updating the application by external decoder's interfaces 140 , 
the loader checks the possibility of updating and if there is such possibility starts to 
exchange applications. However, if it is possible to exchange applications with the use of 
signals, broadcasted in a satellite, cable or terrestrial television signal, received by the 
signal receiving block 110 , the loader adjusts itself to the appropriate data stream, using 
the parameters recorded in the NV-RAM memory. The loader starts the procedure of 
updating the application, checking if the currently broadcasted program in the stream is 
dedicated to a digital television decoder, from which the loader was started. If it is so, the 
updating procedure is accepted. 



The loader can also be started at a request of the user or activated by a specific 
signal from the side of the broadcaster. The broadcaster can send a signal informing 
about a new version of software available, and the recipient after receiving this 
information can issue a request of starting the loader or the loader can be started 
automatically. Additional information can be sent in this signal, which specifies the 
source and the type of the sent data. Both, the application code and the code of the 
loader are stored in the FLASH type memory 150 available in the digital television 
decoder. Fig. 2 illustrates the organization of FLASH type memory of a digital television 
decoder, illustrated in fig. 1. FLASH type memory is divided into four parts. The first part 
201 includes software of the decoder, and the second part 202 is a free storage area, if 
such is available. The next part 203 contains optional application data, and the last part 
is the code of the loader 204 . In most cases, the storage area available for the code of 
the loader is 128 Kilobytes. In the beginning of the start of the loader its whole code is 
copied to the RAM type memory 160 available in the digital TV decoder. 

Fig. 3A illustrates the algorithm of starting the loader. In step 301 the bootstrap is 
started. It starts to work directly after switching on the power supply of the digital TV 
decoder or after setting the default values (restart) of the system. The procedure 
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optionally initiates the FLASH type memory depending on the configuration and checks 
the current status of the digital TV decoder in order to establish, for example, if the 
loader or application program should be started. In step 302 the initiating part is 
executed, which depends on the hardware configuration of the decoder, for example the 
program code is copied from FLASH type memory to RAM type memory. In step 303 the 
main () function is invoked, which starts the loader, and in step 304 the loader is 
realized. 

Fig. 3B presents the algorithm of starting a compressed loader according to the 
invention, which is applicable especially in enhanced configurations. In certain 
configurations the loader's code is so enhanced that it is impossible to place it in the 



128 kilobytes available in the FLASH type memory 150. In order to decrease the 
capacity of the loader a compression of its code is used. Introduction of the compression 
of the loader's code influences the increase of the size of available memory for example 
for enhanced drivers of separate parts of the decoder of digital television such as a 
modulator or a tuner. In such case the code of the loader consists of: the real application 
of the loader and the decompressing module (restoring the primary structure of the 
loader's code) which decompresses the appropriate code of the loader to RAM type 
storage 160 available in a decoder of digital television. The procedure of starting the 
program, compressed in this way, is divided into two parts. The first part, which consists 
of the steps 305, 306, 307, 308, 309, 310, is serviced by the decompressing program. 
The second part, which consists of step 311. is serviced by the loader. In step 305 the 
bootstrap is started after the power supply of the digital TV decoder is switched or after 
initial values of the system are set (restart). In step 306 the code from FLASH type 
memory to RAM type memory is copied. In step 307 decompression takes place 
(unpacking, restoring the primary form of the code) of the program to the RAM type 
memory of the digital TV decoder. In step 308 verification of the decompressed program, 
it is the code in the primary form, takes place. Next, in step 309 the jumps table, which 
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was shown in fig. 7, is initiated. In step 310 the main () function, which starts the loader, 
is executed. In step 311 the loader is started. 

Uncompressed loaders can be located in any area of the available memory. In 
case of a compressed loader constant memory addresses are used, so that the 
references to the places with variables, constants or pointers to the functions are 
correct. That is why; it is assumed additionally that the decompressed loader's code is 
located at a constant address of RAM type memory. In order to prevent the linker from 
adding procedures, which are normally added when the code is located in a RAM type 
memory, it is necessary to inform the linker that this area, dedicated to the loader, is a 
ROM type memory. 
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During the linking of procedures by the linking program all modules of a given program 
are fetched, information is complemented with references between separate modules, 
final addresses are dedicated to the functions and the data, for which it was not done at 
the stage of compilation of the program, and the output program is generated. 

Servicing the compressed loader requires a special approach to the operation of 
placing programs and their data in FLASH type memory. It is assumed that RAM type 
addresses start with address OxCOOOOOOO and the size of memory is equal to eight 
megabytes and four megabytes for a FLASH type memory. Increase of the available 
memory of RAM type causes that there is an increase of the quantity of available space 
for the area of general dedication. The addresses of other areas are constant. 

Fig. 4 shows organization (division) of the RAM type storage in details. Block 401 
represents the area reserved by the loader, that is the memory area reserved for OSGL 
drivers (abbreviation of On Screen Graphic for Loader) and DMUX (abbreviation from 
DeMUItipleXer submodule), controlling the filtering of the data, which are dedicatee* for 
the loader and come to the decoder of digital television. 



Address: 


OxCOOOOOOO 


Size: 


256 kB 



Block 402 represents a start sequence of the loader that is the memory area, 
which includes the block of the start code. The address of the first byte from area 402 
(OxC0040000) is a start point for the loader. 



Address: 


0xC0040000 


Size: 


64 kB 
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Block 403 represents the memory area reserved by the jumps table of the loader 
to the common functions for the loader and decompressing module (restoring, the 
primary form of the code). 



Address: 


OxC0040040 


Size: 


960 kB 



Block 404 represents the memory area occupied by the code of the loader after 
decompression and by the static data of the loader, for example constants or static 
variables. 



Address: 


0xC0040400 


Size: 


255 kB 



Block 405 represents the memory area occupied by the code of the 
decompressing program and by the static data of the decompressing program, for 
example constants or static variables. 



Address: 


OxC0080000 


Size: 


20 kB 



Block 406 represents the area of general dedication, reserved in the memory. 
The area 406 represents the range of addresses dedicated both to the data of the 
decompressing program, including the compressed code of the loader and the code of 
the loader's module. 

The use of the compressed loader in the decoders of digital television requires a 
procedure of creating the RAM memory image. 
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In order to perform this procedure after compilation and linking two files are created, 
including the memory image. In certain systems they are marked with 'hex' extension. 
The first includes a start sequence of the loader located in block 402; the second is a 
memory segment including static data and the loader's code, situated in block 404 . 
Blocks 402 and 404 are used to create the image of RAM type memory. 

Fig. 5 illustrates the procedure of creating the compressed memory image. After 
the start, in step 501, files with memory image are read. In step 502 the input files are 
checked in relation to the memory image. That is if static data and the loader's code are 
located in the appropriate range of addresses. If the files are incorrect, information about 
an error is displayed in step 506 and the procedure ends in step 506. In case the files 
are correct, an image of RAM type memory is created in step 503 . Such image 
constitutes a bytes table comprised sequentially of the areas 402, 403, 404 of the 
memory. At the stage of creating memory image of RAM type, area 403 is filled with 
nulls. In step 504 the memory image is compressed, and in step 505 a header file of the 
loader is created, including a compressed RAM type memory image and information 
required for correct decompression and planting the code of the loader in the RAM type 
memory. 



The header file of the loader includes the following options for the decompressing 
module: 

- loader_area_start_addr - address of the location in memory, where the start 
sequence of the loader starts - block 401 ; 

- loader_area_size - a variable defining the size of the block accessible for the 
loader; 

- loader_code_s/ze - a variable defining the size of the code after the compression 
operation is executed; 

- compressed_loader_crc - a checksum of the compressed code of the loader; 

- loader_compression - the selected compression type; 

- originaLcode_addr - the address of the loader's code after decompression - 
block 404; 



- original_code_size - the size of the code of the loader before compression; 

- original_code_crc - a checksum of the loader's code before compression. 

Fig. 6 illustrates the procedure of the operation of the program decompressing the 
loader. The header file of the loader is used by the module of decompressing 
program a part of which it constitutes. In step 601 decompression of the loader's 
code to RAM type memory takes place under the address 0x0040400. In step 
602 it is checked if an error occurred during the decompression of the code. In 
case an error occurs, there is a transition to step 607 . If there is no error, then in 
step 603 the CRC checksum of the decompressed loader is calculated and there 
is a transition to step 604 , where a check is performed if the CRC checksum is 
correct. If the checksum is incorrect a transition to step 607 is made. In case the 
checksum is correct, first a transition to step 605 is made, where the 
decompressing program initiates the jumps table of the loader, which is illustrated 
in fig. 7, and next a transition to step 606 is made. Initiation of the jumps table is a 
part of the decompressing process and it is performed by filling it up with 
appropriate addresses. In step 607 the procedure checks, if the application code 
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is correct and next in step 608 it checks if there was any error. If no error 
occurred, initial parameters are set for the digital television decoder in step 609 
and the procedure ends its operation starting the application. If there was any 
error, a transition is made to step 610 , where the procedure sets the initial 
parameters for the decoder. The checksums are counted for memory images 
before and after the compression, so that the decompressing program can check 
the correctness of the loader's code before compression and after 
decompression. 

Fig. 7 shows the jumps table of the loader. The table is a set of addresses. 
Every one of these addresses occupies the space of four bytes. The table is 
started by a base address 701 of the global static variables. The next addresses 
are; address 702 of the function initiating the table used for calculating the CRC 
checksums; address 703 of the function calculating the CRC checksum 16; 



address 704 of the function calculating the CRC checksum 32; address 705 of the 
function calculating the CRC MPEG32 checksum; address 706 of the A function 
for decompression of the loader; and address 707 of the B function for 
decompression of updating data. There are two decompressing functions, 
because the loader can be compressed with another compression method than 
the updating data, which are being received. 

The application of the compressed loader makes it possible to use a 
greater quantity of drivers and decreases the required size of the non-volatile 
memory, for example FLASH type memory, which is more expensive than the 
RAM type memory when we compare the price per a unit of memory. As 
opposed to the solutions known from PC computers the application of 
compression in devices, which do not have a hard disk, is much more difficult 
because of the requirement of creating appropriate structure of RAM type 
memory and the use of this structure. Moreover the solution uses memory images 
and not executable files as it is practiced in the current state of technique. 
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1. The receiver of data signal, programmed by a loader, including a signal 
receiving block, the processor, interfaces, RAM, ROM, NV-RAM memory type 
and non-volatile memory, characterized in that the processor includes the 
internal block (121 . 122) . initiating the work of the loader and the block of 
servicing the loader (122, 222) . which on the basis of the code, initiated by the 
initiating block (121 . 122), controls the operation of the loader, which is 
recorded in a compressed form in the non-volatile memory (150 , 250) . After 
being decompressed, it is recorded in the part of the RAM type memory (160, 
260 ) declared as ROM type memory. 

2. The receiver of data signal, according to claim 1 , characterized in that the 
memory image is made of the part including the start sequence of the loader, 
the part including the jumps table of the loader and the part including the area 
of static data of the loader and the code of the loader and in a compressed 
form it is recorded in the non-volatile memory (150, 250). 
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3. The receiver of data signal, according to claim 1 , characterized in that the 
jumps table of the loader includes addresses of common functions for the 
decompressing program and the loader. These functions are defined in the 
decompressing program. 

4. The receiver of data signal, according to claim 1, characterized in that the 
decompressed code of the loader is located under a constant address in the 
RAM memory. 
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5. The receiver of data signal, according to claim 1, characterized in that the 
non-volatile memory (150 . 250) is a FLASH type memory. 

6. The method of updating software in the data receiver by means of the loader 
stored in the non-volatile memory, including the signal receiving block, the 
processor, interfaces, RAM, ROM, NV-RAM memory type and non-volatile 
memory, characterized in that the updating software is recorded in a 
compressed form in the non-volatile memory (150 , 250) and during the 
activation of the start procedure it is copied under a constant address in the 
part of RAM type memory ( 160 , 260) . which before the coupling process was 
declared as a ROM type memory. 

7. The method of updating software in a receiver, according to claim 6, 
characterized in that the start procedure of the loader is executed at the 
moment of plugging the receiver to the power supply. 

8. The method of updating software in a receiver, according to claim 6, 
characterized in that the start procedure of the loader is activated on the 
request of the user. 



9. The method of updating software in a receiver, according to claim 6, 
characterized in that the start procedure of the loader is activated by the 
external signal, being sent to the receiver. 

10. The method of updating software in a receiver, according to claim 6, 
characterized in that the memory image is created from the part including the 
start sequence of the loader, the part including the jumps table of the loader 
and the part including the area of static data of the loader and the code of the 
loader and next the memory image compresses itself. 
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11. The method of updating software in a receiver, according to claim 6, 
characterized in that the table is created, including the addresses of the 
common functions for the decompressing program and the loader. The 
mentioned functions are defined in the decompressing program. 

12. The method of updating software in a receiver, according to claim 6, 
characterized in that the loader starts the procedure of updating the 
application by checking if the program, currently broadcasted in the stream is 
dedicated to the receiver, from which the loader was started, which is a 
condition for updating the application. 
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